一、今日目標

延續 Day 21「第一次建立 ASP.NET Core Web API」及 Day 22「規劃智慧醫院資料庫」，今天開始進行 ASP.NET Core 與 Oracle Database 的實際連線。

前面已經完成主要 Angular 前端頁面，也建立了 ASP.NET Core Web API，並規劃七張資料表及 ERD。

不過，目前後端只有簡單的 HelloController，還沒有真正連接資料庫。

因此 Day 23 的目標，就是讓 ASP.NET Core 可以透過 Oracle 驅動程式，使用一般開發帳號連接 Oracle Database，執行簡單 SQL 並取得結果。

本次主要目標：

• 確認本機 Oracle Database 環境。
• 確認 Oracle Listener 與 Service Name。
• 了解 Oracle 管理員帳號與一般開發帳號的差異。
• 建立智慧醫院專用的 Oracle 開發帳號。
• 使用 SQL Developer 測試資料庫連線。
• 認識 ADO.NET 與 Oracle .NET 驅動程式。
• 學習安全保存資料庫連線密碼。
• 使用 ASP.NET Core 連接 Oracle。
• 透過 C# 執行 SELECT 1 FROM DUAL。
• 驗證 API 是否成功回傳 JSON。
• 確認原本的 Hello API 沒有受到影響。

本次只完成資料庫連線，不執行 Day 22 的七張資料表 DDL，也不實作正式醫師查詢或預約掛號 API。

---

二、從資料庫設計進入實際連線

Day 22 已經完成智慧醫院平台的初版資料庫設計。

當時主要規劃七張資料表：

資料表	用途
Users	會員帳號與聯絡資訊
Patients	實際就診者
Departments	科別
Doctors	醫師
DoctorSpecialties	醫師專長
DoctorSchedules	門診排班與名額
Appointments	預約紀錄

當時也完成了資料字典、主鍵與外鍵、Mermaid ERD，以及 Oracle SQL DDL 草稿。

但這些成果仍然只是設計文件。

真正的資料庫還沒有建立上述七張資料表，ASP.NET Core 也還沒有和 Oracle 連線。

因此今天先不急著建立所有資料表，而是從最基本的資料庫連線開始。

我希望先確認：

1. Oracle Database 是否正常執行。
2. 是否有適合專案使用的開發帳號。
3. C# 是否能成功連接資料庫。
4. ASP.NET Core 是否能取得 SQL 查詢結果。

等這些都成功後，未來才能進一步實作醫師查詢、預約掛號及資料庫 CRUD。

---

三、認識 Oracle Database 與開發工具

開始操作之前，我先釐清 Oracle Database、SQL Developer 與 Oracle .NET 驅動程式的差異。

Oracle Database

Oracle Database 是真正負責儲存及管理資料的資料庫系統。

未來智慧醫院的會員、醫師、門診及預約資料，都會保存在資料庫中。

Oracle SQL Developer

SQL Developer 是用來連接及管理 Oracle Database 的工具。

可以透過它：

• 建立資料庫連線。
• 執行 SQL。
• 查看資料表。
• 查詢資料。
• 管理有權限操作的資料庫物件。

但 SQL Developer 本身不是資料庫伺服器。

Oracle .NET Driver

ASP.NET Core 不能直接使用 SQL Developer 的連線設定來存取資料庫。

它需要透過適合 .NET 的 Oracle 驅動程式，建立自己的資料庫連線。

這次開始了解，資料庫可以由不同客戶端連接：

SQL Developer
       │
       ├────────→ Oracle Database
       │
ASP.NET Core Web API
       │
       └────────→ Oracle Database

SQL Developer 成功連線，不代表 ASP.NET Core 已經成功串接。

因此兩個階段都需要分別測試。

---

四、確認本機 Oracle Database 環境

這次先檢查電腦原本的 Oracle 安裝狀態。

檢查後確認，Oracle Database 與 Listener 服務都已經在執行。

Listener 顯示 orcl 服務處於 READY 狀態。

另外，也確認本機已經有 SQL*Plus 工具。

之後透過 SQL Developer 查詢，確認實際 Oracle 環境：

項目	實際結果
Oracle Database	19c Enterprise Edition
資料庫版本	19.3.0.0.0
Database Name	ORCL
CDB	NO
Host	localhost
Port	1521
Service Name	orcl

CDB 是什麼？

這次第一次接觸到 Oracle 的 CDB 與 PDB 概念。

CDB 是 Container Database，PDB 則是 Pluggable Database。

透過查詢：

SELECT name, cdb
FROM v$database;

得到：

NAME    CDB
----    ---
ORCL    NO

表示目前使用的是非 CDB 架構。

因此這次不需要另外尋找可插拔資料庫 PDB。

確認資料庫架構後，才比較清楚後續應該使用哪個 Oracle Service。

---

五、了解 SID 與 Service Name

這次在 SQL Developer 設定連線時，遇到一個之前沒有特別注意的地方。

Oracle 連線設定中，可以看到：

• SID
• Service Name

原本建立的 SQL Developer 連線名稱為：

SmartCare-Local

而實際使用的設定是：

Hostname：localhost
Port：1521
SID：orcl

一開始容易將連線名稱、SID 與 Service Name 混在一起。

但這三個概念並不相同。

Connection Name

只是 SQL Developer 裡自己設定的連線名稱。

SID

用來識別 Oracle 資料庫執行個體。

Service Name

用來識別客戶端要連接的資料庫服務。

為了確認實際 Service Name，這次執行：

SELECT name, network_name
FROM v$services;

查詢結果包含：

orcl
orclXDB
SYS$BACKGROUND
SYS$USERS

其中確認 orcl 是可用於本機資料庫連線的服務名稱。

因此後續 ASP.NET Core 的 Oracle 連線規劃，使用：

Host：localhost
Port：1521
Service Name：orcl

這次也學到，設定資料庫連線時不能只看 SQL Developer 的連線名稱，而是應該確認真正的資料庫服務資訊。

---

六、為什麼不能直接使用 SYS 帳號？

第一次成功連線 SQL Developer 時，我使用的是 Oracle 的管理員帳號。

執行：

SELECT USER FROM DUAL;

結果為：

SYS

當時的連線角色是：

SYSDBA

雖然已經可以成功查詢 Oracle，但這並不適合作為智慧醫院後端的正式連線方式。

因為 SYS 是具有高度管理權限的帳號，主要用於資料庫管理工作。

如果讓一般 Web API 使用這種帳號，將會賦予應用程式不必要的資料庫權限。

因此這次決定另外建立智慧醫院專用的開發帳號。

希望做到：

• 管理員帳號負責必要的資料庫管理。
• 開發帳號負責一般資料庫連線與測試。
• 未來應用程式只使用需要的權限。
• 不使用 SYS／SYSTEM 作為日常 API 連線帳號。

這也是這次第一次實際接觸「最小權限原則」的地方。

---

七、建立 SMARTCARE_DEV 開發帳號

確認 Oracle 資料庫環境後，接著準備智慧醫院專用的開發帳號。

帳號名稱規劃為：

SMARTCARE_DEV

建立前，先檢查資料庫中是否已經存在相同帳號：

SELECT username, account_status
FROM dba_users
WHERE username LIKE '%SMARTCARE%'
ORDER BY username;

檢查後沒有找到既有的 SMARTCARE_DEV 帳號，因此才進行新的開發帳號建立。

這次建立的是一般資料庫使用者，而不是另一個資料庫。

接著授予最基本的連線權限：

GRANT CREATE SESSION TO SMARTCARE_DEV;

CREATE SESSION 允許使用者建立資料庫工作階段，也就是登入 Oracle。

這次還沒有授予建立正式醫院資料表需要的權限。

因為今天只是連線測試，不需要提前提供大量權限。

另外，建立帳號時使用的密碼由我在本機自行設定，沒有寫入專案原始碼或文章。

---

八、使用 SQL Developer 測試開發帳號

完成帳號建立後，接著在 SQL Developer 建立新的連線。

這次使用：

項目	設定
Connection Name	SmartCare-Dev
Username	SMARTCARE_DEV
Role	Default
Connection Type	Basic
Hostname	localhost
Port	1521
Service Name	orcl

這次和之前最大的差異，是不再使用 SYS／SYSDBA。

建立連線後，點擊 Test，成功通過。

測試目前登入帳號

執行：

SELECT USER FROM DUAL;

結果：

SMARTCARE_DEV

代表已經使用開發專用帳號登入。

測試基本 SQL

接著執行：

SELECT 1 FROM DUAL;

結果：

1

這代表目前的開發帳號可以成功連接 Oracle Database，並執行基本查詢。

不過這時只完成 SQL Developer 的連線測試，還沒有完成 ASP.NET Core 串接。

連線成功截圖：

查詢截圖：

---

九、認識 ADO.NET 與 Oracle 驅動程式

確認 Oracle 本身可以連線後，接著回到 ASP.NET Core 專案。

這次需要讓 C# 程式與 Oracle Database 溝通，因此開始學習 ADO.NET。

ADO.NET 是什麼？

ADO.NET 是 .NET 應用程式存取資料來源的一組技術與介面。

它可以透過資料提供者，建立連線、執行 SQL 並取得結果。

這次使用 Oracle 對應的 .NET 驅動程式：

Oracle.ManagedDataAccess.Core

為什麼需要 Oracle 驅動程式？

因為 ASP.NET Core 本身不會自動知道應該如何與 Oracle Database 溝通。

因此需要適合 Oracle 的資料提供者。

本次主要學習兩個類別：

OracleConnection

負責建立及管理 Oracle 資料庫連線。

OracleCommand

負責將 SQL 指令交給 Oracle 執行。

這次先從簡單的 ADO.NET 查詢開始，沒有直接使用 Entity Framework Core 或 DbContext。

我希望先理解資料庫連線與 SQL 執行的基本過程，再學習更完整的資料存取架構。

---

十、了解 Connection String

ASP.NET Core 要連接 Oracle，需要知道資料庫在哪裡，以及應該使用哪個帳號。

因此這次也開始了解 Connection String（連線字串）。

連線字串通常需要包含：

• Host。
• Port。
• Service Name。
• User ID。
• Password。

本次的非敏感設定包括：

Host：localhost
Port：1521
Service Name：orcl
Username：SMARTCARE_DEV

密碼則另外保存。

為什麼不能將密碼直接寫在程式碼中？

如果直接將 Oracle 密碼寫入 Program.cs 或其他準備提交到 GitHub 的檔案，就可能不小心將密碼公開。

尤其這個專案除了開發功能，也是準備放到 GitHub 的學習作品集。

因此這次特別將密碼管理與程式碼分開。

---

十一、使用 User Secrets 保存資料庫密碼

這次使用 ASP.NET Core 的 User Secrets 保存本機開發需要的 Oracle 密碼。

User Secrets 可以將開發用敏感設定存放在專案原始碼目錄之外。

這樣不需要直接將密碼寫入：

Program.cs
appsettings.json
GitHub

不過 User Secrets 本身並不是加密保險箱，主要用途是降低開發密碼被意外提交到版本控制的風險。

正式部署時仍需要使用更適合的機密管理方式。

本次的設定方式

這次 Codex 準備了一個密碼設定腳本：

tools/set-day23-oracle-secret.ps1

這個腳本會要求在本機終端機輸入 SMARTCARE_DEV 密碼，再將設定提供給 .NET User Secrets。

由於涉及密碼，這個操作需要由我自己在本機執行。

這次沒有把密碼貼進 Codex 對話，也沒有將完整連線字串輸出到日誌。

---

十二、遇到 PowerShell 7 無法辨識的問題

在設定 User Secrets 時，這次實際遇到一個問題。

原本要在 PowerShell 執行：

pwsh -NoProfile -File .\tools\set-day23-oracle-secret.ps1

但終端機出現錯誤：

pwsh : 無法辨識 'pwsh' 詞彙是否為 Cmdlet、
函數、指令檔或可執行程式的名稱。

一開始需要確認是不是沒有安裝 PowerShell 7。

後來檢查發現，電腦其實已經安裝 PowerShell 7，只是沒有加入 PATH。

實際版本

項目	版本
Windows PowerShell	5.1.26100.9767
PowerShell 7	7.5.1

PowerShell 7 的實際位置：

C:\Program Files\PowerShell\7\pwsh.exe

因此問題不是 PowerShell 7 不存在，而是終端機無法直接透過 pwsh 找到它。

解決方式

後來改成使用完整路徑執行：

& "C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -File "C:\Users\Sy\Smart-Hospital2\tools\set-day23-oracle-secret.ps1"

這樣不需要重新安裝 PowerShell 7，也不需要立即修改 PATH。

另外，因為腳本本身使用 PowerShell 7 的功能，所以不能直接改成 Windows PowerShell 5.1 執行。

這次讓我了解到，執行指令失敗不一定代表工具沒有安裝，也可能和系統環境變數有關。

---

十三、成功設定 Oracle User Secrets

修正 PowerShell 的執行方式後，重新執行密碼設定腳本。

依照提示，在本機終端機輸入 SMARTCARE_DEV 的密碼。

完成後顯示：

Oracle password saved

這代表密碼設定步驟已經成功。

不過，這時還不能直接認定資料庫串接完成。

因為成功保存 User Secrets，只表示 ASP.NET Core 已經具備讀取連線設定的條件。

仍然需要透過 C# 真正開啟 OracleConnection，執行 SQL，才能驗證整個資料庫連線流程。

這也是本次將「設定成功」與「連線成功」分開測試的原因。

---

十四、使用 ASP.NET Core 建立 Oracle 連線

完成設定後，開始進行這次最重要的部分：讓 ASP.NET Core 透過 C# 連接 Oracle。

本次採用最小 ADO.NET 方式，不使用 EF Core。

主要流程：

ASP.NET Core Web API
        ↓
讀取 User Secrets 中的連線設定
        ↓
OracleConnection
        ↓
開啟 Oracle 資料庫連線
        ↓
OracleCommand
        ↓
執行 SELECT 1 FROM DUAL
        ↓
取得查詢結果
        ↓
回傳 JSON

OracleConnection

OracleConnection 負責管理 C# 程式與 Oracle Database 之間的連線。

這次學到，建立連線物件與真正開啟連線是不同的動作。

只有當程式實際開啟連線時，才會嘗試與 Oracle 進行通訊。

OracleCommand

連線成功後，接著透過 OracleCommand 執行 SQL。

這次使用：

SELECT 1 FROM DUAL;

因為它不需要事先建立 Users、Doctors 或 Appointments 等資料表。

這讓本次測試可以專注在資料庫連線本身，而不會受到尚未建立的業務資料表影響。

為什麼需要釋放連線？

資料庫連線會使用系統及資料庫資源。

因此程式應該在操作完成後正確釋放連線，不應讓不再使用的連線一直佔用資源。

這次也開始認識 C# 資源管理的重要性。

（這裡建議放入 ORACLE-DAY23.md 中實際的 OracleConnection 與 OracleCommand 程式碼截圖，避免以示意程式取代真正寫入專案的內容。）

---

十五、建立 Oracle 診斷 API

為了驗證 ASP.NET Core 是否能成功連接 Oracle，這次加入了專門的 Oracle 診斷 API。

這支 API 的主要用途不是處理醫師或預約資料，而是測試：

• 後端是否能讀取資料庫設定。
• 是否能使用 SMARTCARE_DEV 連接 Oracle。
• 是否能成功執行 SQL。
• 是否能取得查詢結果。
• 是否能將結果轉換成 JSON 回傳。

本次只執行：

SELECT 1 FROM DUAL;

沒有執行任何新增、修改或刪除資料的 SQL。

而且資料庫診斷功能應限制在本機開發環境，不應作為正式系統公開的診斷入口。

---

十六、第一次成功讓 ASP.NET Core 查詢 Oracle

完成 C# 連線功能後，接著進行實際測試。

這次由 ASP.NET Core Web API 發送 Oracle 查詢，成功取得結果。

實際測試

項目	結果
Oracle 診斷 API	HTTP 200
使用帳號	SMARTCARE_DEV
SQL	SELECT 1 FROM DUAL
查詢結果	1
回傳格式	JSON

實際回傳：

{
  "status": "ok",
  "value": 1
}

其中：

"status": "ok"

表示診斷 API 回報測試成功。

而：

"value": 1

表示 Oracle SQL 查詢實際取得了數值 1。

這個結果代表什麼？

這次已經不只是 SQL Developer 可以連線。

而是 ASP.NET Core Web API 本身已經透過 Oracle .NET 驅動，成功向 Oracle Database 發送 SQL，並取得查詢結果。

這也是 Day 23 最重要的成果。

建議截圖：

（放入 Oracle 診斷 API 回傳 JSON 的畫面）

---

十七、執行 dotnet build 與 Hello API 回歸測試

完成 Oracle 連線後，還需要確認原本的 ASP.NET Core 專案沒有因為新增功能而受到影響。

1. dotnet build

這次執行後端建置。

結果：

Build succeeded.

0 Warning(s)
0 Error(s)

表示目前新增的 Oracle 連線程式沒有造成編譯錯誤。

2. Hello API

原本 Day 21 建立的：

GET /api/hello

仍然成功回傳 HTTP 200，且 JSON 內容正確。

3. Oracle 診斷 API

新增的 Oracle 診斷功能也成功回傳 HTTP 200。

4. 檔案保護比對

這次另外確認原本 Angular 與 HelloController 等受保護檔案沒有受到修改。

實際結果：

133 個檔案一致
0 個變更

因此 Day 23 主要新增的是 Oracle 資料庫連線相關功能，沒有修改原本的 Angular UI 或 HelloController。

---

十八、這次連線成功，但還沒有建立正式資料表

雖然 ASP.NET Core 已經成功連接 Oracle，但這次仍然沒有建立 Day 22 規劃的七張資料表。

目前完成的是：

ASP.NET Core
      ↓
Oracle Database
      ↓
SELECT 1 FROM DUAL
      ↓
回傳 1

尚未完成的是：

ASP.NET Core
      ↓
Oracle Database
      ↓
Users / Doctors / Appointments
      ↓
讀取正式資料

這兩個階段不能混為一談。

今天證明了資料庫連線與簡單查詢可以正常運作。

但尚未驗證：

• CREATE TABLE 是否能成功執行。
• Primary Key 與 Foreign Key 是否正常生效。
• Oracle 實際欄位型別是否符合預期。
• 是否能 INSERT 或 SELECT 醫師資料。
• 預約名額與重複預約規則。
• Angular 與正式資料庫 API 的整合。

這些都會留到後續階段再處理。

---

十九、今日學習

這次主要學習：

• Oracle Database 與 SQL Developer 的差異。
• Oracle Listener 的用途。
• SID 與 Service Name 的差別。
• Oracle CDB 與非 CDB 架構。
• Oracle SYS／SYSDBA 管理員帳號。
• 為什麼應用程式應使用專用開發帳號。
• CREATE SESSION 的用途。
• SQL Developer 的連線設定。
• SELECT USER FROM DUAL。
• SELECT 1 FROM DUAL。
• ADO.NET 的基本概念。
• Oracle.ManagedDataAccess.Core 的用途。
• OracleConnection 與 OracleCommand。
• Connection String。
• ASP.NET Core User Secrets。
• PowerShell 5.1 與 PowerShell 7 的差異。
• PATH 環境變數與指令執行。
• API 回傳 JSON 與 HTTP 200。
• 後端回歸測試的重要性。

這次最大的學習，是理解資料庫連線並不只是輸入帳號密碼，而是包含資料庫服務確認、權限管理、驅動程式、連線設定與程式測試等不同環節。

二十、AI 協助與成果

1. AI 協助

本次使用 Codex 協助：

• 檢查 Oracle Database 與 Listener。
• 確認 Oracle Service Name。
• 協助分析資料庫版本與容器架構。
• 規劃 SMARTCARE_DEV 開發帳號。
• 提供 SQL Developer 查詢與測試方式。
• 分析 Oracle .NET 驅動程式。
• 規劃 User Secrets 的安全設定方式。
• 檢查 PowerShell 7 PATH 問題。
• 建立 Oracle 連線相關程式。
• 執行 ASP.NET Core 與 Oracle 的連線驗證。
• 確認 Hello API 沒有受到影響。
• 整理技術文件及測試紀錄。

2. 今日成果

本次已完成：

• 確認本機 Oracle Database 19c 可以正常運作。
• 確認 localhost、Port 1521 與 Service Name orcl。
• 建立 SMARTCARE_DEV 開發帳號。
• 成功使用 SQL Developer 查詢 Oracle。
• 使用 User Secrets 保存開發密碼。
• 解決 PowerShell 7 無法直接辨識的問題。
• 成功使用 ASP.NET Core 連接 Oracle。
• 成功執行 SELECT 1 FROM DUAL。
• Oracle 診斷 API 回傳 HTTP 200。
• 原本 Hello API 回歸測試成功。
• 原有 Angular 與 HelloController 保持不變。

3. 開發紀錄文件

這次整理的文件包括：

docs/
├── ORACLE-DAY23.md
├── DAY23-TECHNICAL-SUMMARY.md
├── day23-environment-check.json
├── day23-hello-test-results.json
└── day23-oracle-test-results.json

其中 ORACLE-DAY23.md 保存分階段教學與 C# 程式碼解釋，其他檔案則記錄環境確認與實際測試結果。

成果截圖：

SQL Developer 的 SMARTCARE_DEV 連線設定:

SELECT USER FROM DUAL 與 SELECT 1 FROM DUAL 的結果:

Oracle 連線相關 C# 程式碼:

Oracle 診斷 API 回傳 JSON:

dotnet build 成功結果:

---

二十、下一步

這次已經完成智慧醫院管理平台 ASP.NET Core Web API 與 Oracle Database 的第一次實際連線。

從 Day 21 建立第一支 API，到 Day 22 規劃七張資料表，再到 Day 23 成功查詢 Oracle，後端開發開始有了更完整的基礎。

目前資料庫連線已經可以正常運作，但尚未真正建立智慧醫院需要的業務資料表。

接下來希望逐步完成：

• 審查 Day 22 的 Oracle DDL 草稿。
• 確認資料表主鍵的產生方式。
• 規劃適當的建表權限。
• 在開發資料庫中建立七張資料表。
• 測試 Primary Key、Foreign Key、UNIQUE 與 CHECK 限制。
• 使用虛構資料測試 INSERT、SELECT。
• 後續再建立正式的醫師查詢 API。
• 最後讓 Angular 透過 ASP.NET Core 取得 Oracle 中的資料。

另外，因為目前專案目錄仍無法辨識為 Git Repository，所以這次尚未進行 Commit。

等確認正確版本庫後，可以將 Day 23 的資料庫連線功能獨立提交，建議使用：

feat(api): add Oracle database connectivity

這次最大的收穫，是第一次讓自己建立的 ASP.NET Core Web API 真正連接到 Oracle Database。

也讓我更清楚了解，前端畫面、Web API 與資料庫之間如何逐步建立真正的資料流通。